The present disclosure relates generally to information handling systems, and more particularly to authenticating a security module when booting information handling systems.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Many information handling systems include chipsets such as, for example, the Platform Controller Hub (PCH) available from INTEL® Corporation of Santa Clara, Calif., United States. Such chipsets may include One-Time-Programmable (OTP) Non-Volatile Memory (NVM) and/or other memory subsystems that utilize fuses such as In Field Programmable (IFP) fuses that may be burned during manufacturing to provide security information in the chipset (e.g., information associated with a public key such as a hash of a master public key) and/or enable particular features in the system. For example, security information provided in the chipset in such a manner and associated with a public key may be utilized to verify software or firmware (e.g., a Basic Input/Output System (BIOS)) that has been signed with an associated private key. Similarly, features enabled in the information handling system in such a manner may include security features such as, for example, BOOT GUARD available in systems provided by DELL® Inc. of Round Rock, Tex., United States, and PLATFORM TRUST TECHNOLOGY available from INTEL® corporation of Santa Clara, Calif., United States. Providing chipsets with information and enabling system features in such manner provides a root of trust for that information and those features.
In a specific example, when a security module such as BOOT GUARD is enabled, it may check authentication results of an Authenticated Code Module (ACM), available from INTEL® corporation of Santa Clara, Calif., United States. If the BOOT GUARD authentication check of the ACM fails, BOOT GUARD does not allow the system to boot. In conventional systems, the ACM may be included in the BIOS storage, and security information in the ACM is then authenticated against security information in a Platform Controller Hub (PCH). However, some computing systems have moved the security information to authenticate the ACM from the PCH to the central processing unit (CPU). As would be understood by one of skill in the art, CPUs may be provided in different versions such as, for example, a production version (also referred to as a Qualification Sample (QS)) or a pre-production version (also referred to as an Engineering Sample (ES)).
With regard to ACM authentication, a pre-production (e.g., a “debug”) ACM may be authenticated with an ES CPU, while a production ACM may be authenticated with a QS CPU. However, a BIOS must select which ACM to use when compiling the BIOS. For example, when the computing system is powered on, the CPU loads the ACM from a firmware interface table (FIT) before the BIOS starts. As such, if the BIOS is built with a pre-production/debug ACM, the BIOS cannot boot a computing system with a QS CPU. Similarly, if the BIOS is built with a production ACM, the BIOS cannot boot a computing system with an ES CPU. These issues introduce complications during the development phases of computing systems when those computing systems may have ES CPUs or QS CPUs. A conventional solution is to provide two BIOS's, with a pre-production/debug ACM to support ES CPUs, and a production ACM to support QS CPUs. BIOS flashing code then checks the installed CPU type (e.g., ES or QS), and only allow BIOS to be updated when a matching ACM and CPU requirement (e.g., both production or both pre-production) is satisfied. However, such solutions require multiple different BIOS versions to perform conventional ACM authentication, and increase the chances of human errors produced in (and human intervention required for) flashing a BIOS. Furthermore, having multiple different BIOS versions increases production costs and manufacturing times, while hindering the supply chain and decreasing the efficiency of the manufacturing process.
Accordingly, it would be desirable to provide an improved security module authentication system.